home *** CD-ROM | disk | FTP | other *** search
/ Mac Format 1995 June / MacFormat 25.iso / Shareware City / Developers / fortran-to-c-translator-11 / Mac F2C 1.1 / Mac F2C Documentation / Mac F2C Known Bugs < prev    next >
Text File  |  1995-02-01  |  7KB  |  126 lines
  1.     ******************************************************
  2.     ******************************************************
  3.  
  4.                    KNOWN BUGS in Mac F2C v1.1 
  5.  
  6.     ******************************************************
  7.     ******************************************************
  8.  
  9. There are several known problems with Mac F2C.  There is one known code 
  10. generation problem, but it is relatively minor and easy to work around.  
  11. The more serious problems are all related to Mac F2C's user interface and 
  12. memory leaks.  These problems come from one of two sources: the use of the 
  13. THINK C console library, and the incorporation of the UNIX version of f2c 
  14. as a subroutine in Mac F2C.
  15.  
  16.  
  17.  
  18. Code Generation Problems
  19. *********************************************
  20.  
  21. There is one code generation problem that I know of.  
  22.  
  23.     - Unlabeled COMMON blocks defined in separate C files and 
  24.       declared Extern 
  25.  
  26.       This problem occurs when the program contains an unlabeled COMMON 
  27.       block and you have selected the options to define the COMMON block in 
  28.       a separate file and declare the block "Extern" in the original file 
  29.       (the factory default behavior).  In this case the C version of the 
  30.       original FORTRAN file will #define a symbolic constant to refer to 
  31.       the COMMON block (which is translated as a struct).  The error is 
  32.       that f2c will include an #undef statement after the end of the first 
  33.       subroutine in the file -- even if subsequent subroutines refer to that 
  34.       symbol.  This produces a preprocessor error when you try to compile 
  35.       the C file (e.g., "Symbol '_BLNK__1' is undefined").
  36.       
  37.       There are two work-arounds for this bug:  
  38.       
  39.         (a) Do not select the options that define COMMON blocks in separate 
  40.         files and define them Extern.  Unfortunately, this will not always 
  41.         work:  multiple definition errors will occur in the C code when the 
  42.         same COMMON block is used in separate files of FORTRAN code.
  43.         
  44.         (b) Go through the C code and delete the spurious #undef lines.  
  45.         This is usually easy to do and is the recommended solution.  The 
  46.         disadvantage is that this is hard to script if you use a scripting 
  47.         tool of any kind to drive the builds of your FORTRAN code.
  48.  
  49.  
  50.  
  51. Problems related to the THINK console library
  52. *********************************************
  53.  
  54. The f2c kernel uses standard I/O calls (fprintf(), fputs(), etc) to display 
  55. status message.  Mac F2C uses the THINK C console library to display these 
  56. messages in a Macintosh ‘status’ window.  Unfortunately, the THINK C 
  57. console library has some undesirable "features" and side effects.  The ones 
  58. I know of are:
  59.  
  60.     - The ‘Edit’ menu ‘Cut’, ‘Paste’, and ‘Clear’ commands do not work on 
  61.       the Mac F2C status window.  The ‘Copy’ command DOES work.
  62.  
  63.     - The Mac F2C status window cannot be scrolled.
  64.  
  65.     - Command-key combinations for commands that are not on the ‘Edit’ 
  66.       menu (e.g., Cmd-Q for Quit, Cmd-O, for Open/Translate) do not work 
  67.       if the Mac F2C status window is the front window.
  68.  
  69. There are probably others I have forgotten or don't know about.  My long 
  70. term solution is to write my own code to catch the standard I/O calls and 
  71. send them to a full-featured, scrollable status window of my own design 
  72. that you will be able to save to a text file.  Although the window itself 
  73. is easy to put together, plugging into the standard I/O mechanism is hard 
  74. because f2c also uses the standard I/O library to read/write from disk.  I 
  75. need to either (a) sift out only those writes to stdout and stderr without 
  76. breaking the other ones, or (b) grab all of them and handle both screen I/O 
  77. and file I/O myself.  Either way, it's more work than I have the time to 
  78. take on right now.  This item is saved for version 2.0...
  79.  
  80.  
  81.  
  82. Problems related to the f2c kernel
  83. *********************************************
  84.  
  85. There are a series of problems that arise because the original UNIX version 
  86. of f2c (a stand-alone program) is incorporated in Mac F2C as a subroutine.  
  87. The original UNIX f2c is designed to compile one file and quit, so lots of 
  88. bugs such as memory leaks and dangling open files don't show up -- all 
  89. memory is released and files are automatically closed when the program 
  90. quits.  In Mac F2C, the original f2c program has been turned into a 
  91. subroutine which can be called several times -- and each time the leaked 
  92. memory is lost to future iterations.  I have fixed the dangling open file 
  93. bugs in f2c, but not the memory leaks.  This means that you can easily run 
  94. out of memory if you translate more than about a dozen FORTRAN files at a 
  95. shot (fewer if they are big or complicated).  The work-around is to 
  96. translate a few files at a time, quit and re-start Mac F2C, and then do a 
  97. few more.  You can also give Mac F2C a bigger memory allocation.
  98.  
  99. I have received numerous suggestions for fixing the memory leak problem.  
  100. They've ranged from implementing my own memory management functions (one 
  101. user kindly provided code to do this), to creating a new heap zone for f2c 
  102. and blowing the whole zone away when f2c finished.  Unfortunately, tracking 
  103. down the memory and freeing it is not the problem.  The real problem is 
  104. that f2c keeps pointers -- many dozens of them -- to that memory.  If I 
  105. just blow that memory away, I'm left with lots and lots of dangling 
  106. pointers.  Some pointers would be easy to re-initialize: they are declared 
  107. as global variables.  All I need to do is write a function that declares 
  108. these variables as extern and set all of them to NULL.  But many other 
  109. variables are declared as static local variables -- I can't get at them in 
  110. one of my own functions.  To be able to re-initialize these I need to 
  111. modify the f2c code.  I can't do this without an extensive re-write of the 
  112. f2c code (just changing them from local static variables to global 
  113. variables doesn't work because many of these local variables have the same 
  114. name).  And I _really_ don't want to do an extensive re-write of the f2c 
  115. code because (a) I'm lazy, and (b) it would become very _painful_ to update 
  116. Mac F2C to newer versions of f2c.  Keeping Mac F2C reasonably current 
  117. vis-a-vis UNIX f2c has always been one of my primary goals, so I'm loath to 
  118. sacrifice that goal to fix the memory problem.
  119.  
  120. The bottom line is that although I know how I could do it, don't expect the 
  121. memory leaks to be fixed in the near future.  What do you -- my users -- 
  122. think is more important: fixing the memory leaks or keeping Mac F2C current 
  123. with UNIX f2c? Let me know at igormt@alumni.caltech.edu.
  124.  
  125.  
  126.